Next Generation Networking is a broad term to describe architectural evolution in telecommunication core and access networks. The general idea behind NGN is that one network transports all information and services (e.g. voice, data, and media such as video) by encapsulation into packets, in a similar manner to that used on the Internet. NGNs are commonly built around the Internet Protocol. Thus an NGN is a packet-based network which can provide services including telecommunications, which is able to make use of multiple broadband, QoS-enables transport technologies, and in which service-related functions are independent from underlying transport-related technologies.
In NGNs, many protocols such as, for example, H.248 (also known as Gateway Control Protocol) are used for controlling the media setup of a call. Protocol messages are processed on the central processing unit (CPU) of corresponding nodes.
Different types of nodes have different signal processing capacity, and some nodes have significantly higher capacity than others. Because of this it is possible to envisage scenarios in which there is a high probability of signalling overload in a specified target node caused by a source node. This may occur, for example, if the signal processing capacity of the target node is significantly lower than that of the source node.
Signalling overload causes system performance degradation even if the target node is able to protect itself by rejecting offers. External overload control mechanisms have therefore been developed to restrict in advance the traffic which can be offered to the target node. Such overload control mechanisms are generally operated by the source node. Call-gapping algorithms are used to decide whether each offer should be sent out to the target.
Where the characteristics of the desired maximum offer throughput are known (determined as part of the external overload control) the decision logic in the source node is referred as a “throttle”. FIG. 1 illustrates the architecture of an external overload control between a source node 101 and target node 102. Offers 103 are sent from the source node 101 and information 104 is returned from the target node 102 towards the source node 101. A throttle 105 is operated by the source node 101 to restrict the flow of offers.
The external overload control mechanism can itself control different types of descriptors of the traffic flows in the system. For example, Windows-based systems control message turnaround time with a throttle limiting the number of offers in the system. Other systems operate by restricting a percentage of offers compared to a previous time period. Many others, such as for example the arrangement described in H.248.11, control the rate of offers and use a “token bucket” as a throttle, as described in more detail below.
The typical requirements that an offer rate limiting throttle must fulfil are as follows:    [Req-1a:] The rate of the offers sent out should be limited according to the rate determined by other parts of the external overload control.    [Req-1b]: An offer should always be sent out once the limit is not violated.    [Req-2]: When only one offer can be sent out and there are two candidates, the one with higher priority should always be sent out.    [Req-3]: When different traffic classes are defined (on the same priority level) and there are candidates not to be sent out because of the limitations, then the offer rate representing the resource should be split according to some defined agreements between the traffic classes (Service level Agreements).
The problem with these requirements is that, once they are put into a real system environment, it is very hard to decide whether or not they are met. Furthermore, different interpretations are possible, and it can even be envisaged that in certain circumstances it is not possible for all of them to be satisfied at the same time.
There are some solutions in existence that solve some of the requirements outlined above. For example, H.248.11 describes a Token Bucket system (although it will be noted that this is defined as a Leaky Bucket in the standard; however the behaviour described is that of a Token Bucket). In the Token Bucket system, the bucket can be seen as an abstract container that holds aggregate network traffic to be transmitted. The bucket contains “tokens”, each of which can represent a unit of bytes or a single packet of predetermined size. Tokens are added to the bucket at a predetermined rate until the bucket is full. Tokens in the bucket are effectively “cashed in” (removed) for the ability to send a packet. The network administrator specifies how many tokens are needed to transmit how many bytes. When tokens are present, a flow is allowed to transmit traffic. If there are no tokens in the bucket, a flow cannot transmit its packets. Therefore, a flow can transmit traffic up to its peak burst rate if there are adequate tokens in the bucket and if the burst threshold is configured appropriately.
The Token Bucket is characterised by a “watermark level” (the maximum peak burst rate; this can also be thought of as the capacity of the bucket) and the maximal offer rate (the rate at which tokens are added to the bucket).
Using this system, the average rate of flow of traffic is kept below a predetermined maximum (the maximal offer rate). In addition, the watermark ensures a maximum allowed peak in traffic. The setting of the watermark parameter determines how likely it is that the bucket produces high throughput rates for short times (which might violate req-1a above) or does not send out candidates even though the rate limit is not violated (which would violate req-1b).
The Token Bucket system does allow for priority handling. Different watermarks are applied for the different priority levels, so the throughput characteristics are different for different priorities: calls with higher priority cause higher peaks in traffic. This addresses req-2.
However, the Token Bucket system does not handle traffic classification, and therefore cannot deal with Service Level Agreements. Req-3 is therefore not addressed.
Other methods, such as Weighted Fair Queuing, address the classification issues of req-3. However, such methods place offers in queues and thus cause delay in the transmission.
There is thus a need for a throttle which provides maximum throughput for traffic of different classes which respects Service Level Agreements but does not employ queues.